Hi @shivylp,

first thanks for implementing this feature!

I'm using your fork in my current project and have some issues on Windows when copying an file before starting the application. I'll always get an error from getClipboardData.Call(cfUnicodetext) in clipboard_windows.go.

I think this is not a problem of your pull request but initially you're setting the currentValue and return if an error occurs. Sadly I can't get this return value when using Goroutines. Or am i wrong?

https://github.com/atotto/clipboard/pull/31/files#diff-f523429d86f9f4660c4360d3d046cee7R27

I'm calling your monitor method in my project at this line and have no access to an error.
https://github.com/hebestreit/clipboard-yt-dl/blob/master/cmd/clipboard-yt-dl/main.go#L80

To solve this problem I've made this changes.

func Monitor(interval time.Duration, stopCh <-chan struct{}, changes chan<- string) error {
	defer close(changes)

	var currentValue string
	
	for {
		select {
		case <-stopCh:
			return nil
		default:
			newValue, _ := ReadAll()
			if newValue != currentValue {
				currentValue = newValue
				changes <- currentValue
			}
		}
		time.Sleep(interval)
	}
}

You can probably do:

go func(){
   if err := Monitor(....); err != nil {
       // some way to handle this error
   } 
}()

If that doesn't work for you, the logic of the Monitor is so simple that you can simply copy and build a usage specific version for your particular usecase.

The first error check was there to ensure this function does not set off an infinite for-loop that doesn't do anything. If the first time ReadAll() fails, we don't know the current value in the clipboard and hence, the currentValue != newValue will simply be false all the time and nothing would be sent over the changes channel.

I'm of your opinion if the error is not produced by a value in the clipboard like init clipboard.

But in my case I want to have that infinite for-loop because at first there is an invalid value for example a copied file but then I copy another value which would replace it successfully.

Just this error or other errors will be ignored inside of the infinite for-loop. So maybe it is possible to distinguish these error types?

For now I've copied your logic of the Monitor and customized it.

Did not see this implementation and reimplemeted it.

Now that I'm done I'm gonna make a PR anyway: #38